Overview of MultiProtocol Router Basic April 15, 1992 NetWare MultiProtocol Router Basic consists of: > Runtime NetWare 3.11 which allows you to: - If you do not already own NetWare 3.11 to have a 3.11 router. - If you already own NetWare 3.11 to set up an additional machine as a 3.11 router. > 3 router performance enhancement NLMs 1. Burst Mode NLM and Shell Burst Mode causes a noticeable improvement in NetWare workstation and server performance. This improvement comes from the NLMs ability to transfer large amounts of data between servers and workstations in response to a single data transfer request. 2. Large Internet Packet Exchange NLM Large Internet Packet Exchange coordinates the packet size between servers and workstations, synchronizing the largest packet size that can be transmitted between any two. This optimizes the use of available bandwidth between any 2 devices, regardless of the packet size of other devices in the network. 3. Service Advertising Filter NLM Service Advertising Filter allows system administrators to select which servers will be visible at various points in the network. A set of administrator selected attributes are used to specify the type of access permitted. MultiProtocol Router Basic is governed by Novell's copyright agreement. However, Burst Mode NLM, Large Internet Packet Exchange NLM and Service Advertising Filter may be duplicated by MultiProtocol Router purchasers for internal use on all servers at their site. > Documentation for Runtime NetWare 3.11 and the performance enhancement NLMs. MultiProtocol Router Basic v1.0 software offers the following features: - IPX, IP, and AppleTalk routing on Ethernet, Token Ring, LocalTalk, and ARCnet. - IPX and IP RIP, AppleTalk RTMP routing protocols. - Remotely management using RCONSOLE or ACONSOLE. TCP/IP can be remotely monitored using SNMP (Simple Network Management Protocol). - Uses standard NetWare security features (encrypted passwords) for system administration. - The Router installs the same as another NetWare 3.11 server. For long distance IPX routing, NetWare Link/64 or Link/T1 can be added to provide wide area IPX (only) connectivity utilizing the performance enhancement NLMs. Refer to TN6RUL.TXT in NOVLIB Library 9 of CompuServe for additional Link/64 and Link/T1 information. HARDWARE & DRIVERS > The Network Interface Card (NIC) MUST be supported by an Open DataLink Interface (ODI) driver. For high throughput it is best to use an EISA NIC or a 32 bit Microchannel NIC. > The router must use a 386 or 486 based computer and has been optimized for performance on such systems. For high throughput use at least a 25 Mhz CPU and a large processor cache memory. > MSDOS or PCDOS versions 3.1 or later. > A minimum of 4M of RAM (additional RAM will improve performance), 20M hard drive, and a high density floppy disk drive. > A keyboard and monitor are required for initial installation, but are not necessary for maintenance and management. PACKET BURST Burst Mode NLM resides on the file server. Once a connection has been made, packets of data are transmitted in bursts, taking advantage of available bandwidth. The current implementation of Burst Mode requires: - Burst Mode NLM to be loaded on the file server - Space in conventional memory at the workstation level - Burst Mode shell (BNETX.COM) to be installed on desired workstations The appendix below lists the drivers that are Novell certified for use with the Burst Mode performance enhancement. Contact the appropriate vendor to ensure you have the latest driver and that it is certified for operation in a bursting environment. For your protection, noncertified drivers should be tested in Burst Mode before use in a live network. Burst Overview The amount of workstation memory needed is based on parameters given to the shell by the user in the NET.CFG file, and the ability of the hardware. The shell will determine upon loading whether the workstation has enough memory. If there is enough memory, a packet burst connection is initiated with the server by the client at connection/login time. (See the "How the Algorithm Works" section below for memory requirements and the implications of machine speed and performance.) At connection time, maximum burst sizes are negotiated with each server connected. Since packet burst is established with each connection, it is possible to "burst" with one server while not bursting with another. Once a burst connection is established between a workstation and a file server, the workstation automatically uses the burst service when ever an application makes a read or write involving more than 512 bytes of data. This means that an application does not have to be burst aware. Burst Transmission Rate Control Algorithm Various factors influence the transmission rate of data on the network, including the following: - Speed of the file server - Speed and available memory of the workstations - Speed and buffer size of the network media - Traffic on the network at transmission time The Burst Mode NLM is sensitive to data transmission factors and interaction between host network elements. For example, a fast file server could overwhelm a congested bridge or slow workstation with a large stream of packets, causing dropped packets. A bursting workstation is able to give up a portion of the bandwidth it is using, if the network becomes congested, and readjust to maximum bandwidth usage when it is available. To maximize the fair and effective transmission rate, the packet burst protocol uses a twofold transmission rate control algorithm. How the Burst Algorithm Works Packet burst uses conventional memory space in the workstation, for burst buffers, even if the expanded or extended memory shell is loaded. The amount of conventional memory, m, in bytes, required for one packet burst buffer is: m = negotiated packet size + 102 For the negotiated packet size value, NetWare negotiates a packet size with Ethernet, for example, of 1024 bytes. The constant 102 is the total number of bytes needed for the IPX, NCP burst, and ECB headers. Thus, the total memory n required for all packet burst buffers, in bytes, is: n = pb buffers * m The value pb buffers is the user-specified number of packet burst buffers (see below), and m is the memory required for one packet burst buffer. When a burst is received, the data is transferred from the hardware to the workstation memory. To maximize performance, you must consider the speed of the workstation as well as the network card being used. Performance optimization, however, will be largely a matter of experimentation. Packet burst is enabled at the workstation by adding a line to the workstation's NET.CFG: pb buffers = In this line, the variable n is a number between 0 and 10. Making n = 0 disables packet burst, while 1 causes the shell to increase the value up to 2. If n > 10, the shell reduces the number to 10, rather than returning an error. Five to eight buffers is usually optimal. If the workstation does not have enough memory for requested buffers, the shell sets the number using available space, without notifying the user. Increasing the value of n does not necessarily lead to better performance. For example, a slow machine cannot move data from the on board buffers to application memory fast enough, regardless of an increased n value. Also, if a network card has on board receive buffers, the pb buffers parameter could be set to a higher number than for cards without those buffers. After figuring the maximum physical packet size and determining that there is enough memory available at the workstation for the number of packet burst buffers requested, the packet burst protocol determines a minimum size for the packet burst data window and allows that minimum to be transmitted regardless of network conditions. (Theoretical maximum window size is 64KB) Burst Connection Setup A workstation sets up a packet burst connection with a file server at attach/login time. Once the packet burst connection is established, it stays up indefinitely. If the shell fails to make a packet burst connection during attach/login, it uses normal NCPs to do the work. This ensures compatibility with servers not running packet burst. When the packet burst connection is made, the following sequence occurs: 1. Workstation and server synchronize (zero) packet and burst sequence number. 2. They exchange packet burst connection Ids. 3. The workstation tells the server the dynamic IPX socket number it is using for packet burst communication. 4. The two sides exchange information about the maximum sizes of packets and bursts each can handle; both use the smaller packet and burst size. Packet Burst is not actually invoked until a large read or write request is made, regardless of when the connection is made. Large Internet Packet Exchange NLM The Large Internet Packet Exchange allows large packet size transmission between server and workstation. Do not use Large Internet Packet Exchange NLM with networks containing ARCnet network segments because the maximum packet size on ARCnet is 512 bytes. This NLM does not recognize the limitation and data would be lost. Large Internet Packet Overview When the workstation logs in or attaches to a file server, they must negotiate a Maximum Packet Size value. This will be either the workstation's Packet Buffer Size or the file server's Packet Buffer Size, whichever is smaller. This is because the file server does not know if routers between the workstation and file server can handle large packet sizes. The Large Internet Packet Exchange NLM intercepts the Negotiate Packet Size request and duplicates the original procedure exactly, except that it ignores the router check. After the Large Internet Packet Exchange NLM has been loaded on each file server, workstations attaching or logging in can use large packet sizes. If a router between the workstation and the file server is not configured to handle larger packet sizes, the workstation will get the message "Error Receiving from Network" the first time it tries to read or execute a file larger than the router can handle. Retrying is useless, and aborting loses the connection. Since the NLM has no way of knowing when such a problem might exist, the system supervisor must intervene to resolve such problems. There are four ways to fix this problem: 1. Configure the router to handle larger packets. 2. Configure the workstation to use smaller packets. 3. Configure the server to use smaller packets. 4. Unload the Large Internet Packet Exchange NLM. Only workstations attaching while the Large Internet Packet Exchange NLM is loaded will be affected by it. When you load the Large Internet Packet Exchange NLM, it becomes active. To deactivate the Large Internet Packet Exchange NLM, unload it. Service Advertising Filter The Service Advertising Filter can be used to reduce the amount of Service Advertising Protocol (SAP) traffic on the network by filtering retransmission through routers. It involves the use of SAFILTER.NLM, SAFENG.NLM and OBJTYPES.NLM. SAP is used by servers and routers to inform all potential clients of the server's presence on the network. Server is used here to mean a service oriented process that may be running on a file server, router, or workstation. Servers using the NLM broadcast their name and type every 60 seconds. NetWare routers (including file servers) rebroadcast SAP information over each of their directly connected networks to ensure that it is properly disbursed. The primary clients of this information are file servers. Routers process SAP information, but the file server stores it in the bindery for easy access. A bindery object is created using the advertised name and type for each advertising entity that does not reside on the server. The object created is dynamic (it will get deleted when the file server is taken down). These bindery objects are what is seen when running a utility such as SYSCON, SLIST, or PCONSOLE to look at the list of known servers. Basically, the Service Advertising Filter lets you determine what servers will be visible at any given point in an internet. There are two main reasons to do this: 1. To reduce the amount of network traffic generated by the SAP broadcasts. On a large internet, the amount of traffic generated by SAP broadcasts can become noticeable, especially on slower links. Also, large amounts of SAP information can come to a file server from remote portions of the network that its users never (or rarely) access. 2. For security. You may have some servers you don't want to be seen except in specific cases. The Service Advertising Filter NLM accomplishes its task by allowing you to control any servers SAP information as it enters or leaves the router. Using the Service Advertising flow control settings, routers and file servers can be placed into one of four categories: 1. Open: a standard NetWare router or server without Service Advertising Filter. 2. Gate: allows all incoming, but no outgoing SAP information. This allows for a controlled crossover point between two otherwise independent networks. 3. Exchange: does not allow SAP traffic in either direction. Since the router continues to advertise itself, it is visible to two separate networks, but provides no means of crossing over server information from one to the other. 4. Other: a hybrid of the above. Generally, this would be a 'Gate' configuration with some routers or servers allowed to be seen as if they were an 'Open' configuration. > SAFILTER.NLM The SAFILTER.NLM allows you to administer device filter attributes for the router on which it is loaded. It is not required for operation of the filter engine, so it may be unloaded (or exited) after you have set up the list. The following options appear in the menu: - Filter List: This is the SAP filter permission list. It is a scrollable list that contains the identity of devices that are allowed to be passed through the filter. Servers are added to or removed from the list by using the and keys. When adding a server, the New Filter Information form appears that asks for the name and type of the server and its filter attributes (IN only or I/O). - Load from/Save to a file: These options allow you to load a Filter List from or to save the current list to a file. The default file name is SYS:SYSTEM\ SAFILTER.DAT. - Incoming SAPs ARE/ARE NOT Filtered: When incoming SAPs are filtered, the filter list is used to screen SAPs entering the router from an interface. If incoming SAPs are not filtered, all incoming SAPs are passed through the interface. This overrides SAP Filter List attributes. - Outgoing SAPs ARE/ARE NOT Filtered: When outgoing SAPs are filtered, the filter list is used to screen SAPs that have entered the router from going into an interface. When not filtering, all SAPs are allowed to pass to the outgoing interface. This overrides SAP Filter List attributes. > SAFENG.NLM SAFENG.NLM must be loaded before any LAN drivers are bound to IPX for your filter attributes to be enforced. > OBJTYPES.NLM OBJTYPES.NLM presents a scrollable list of object types, numbers, names, and a flag indicating whether or not a type uses the Service Advertising Filter NLM. The file provided contains the standard object types used by Novell. This utility allows you to update the list as needed. APPENDIX Novell certified LAN and disk drivers released after NetWare 3.11 and current as of 4/92. These drivers have been tested with the Burst Mode NLM performance enhancement. Since certification is an on going process you should consult NOVLIB (on CompuServe) and/or the hardware vendor for the latest available driver information. IMSPL2.ZIP and IMSPD.ZIP for disk Library Dedicated IPX Drivers Driver File Size Date S3C503.OBJ 6,319 6-14-91 S3C505.OBJ 9,534 5-08-91 S3C523.OBJ 7,841 2-26-91 SLANSUP.OBJ 6,080 10-18-91 SNE2100.OBJ 4,802 2-19-91 SPCN2.OBJ 5,911 5-03-91 STOKEN.OBJ 6,683 8-23-91 DOS ODI Drivers Driver File Size Date 3C1100.COM 12,288 11-12-91 3C501.COM 11,838 3-19-91 3C503.COM 14,821 6-14-91 3C505.COM 25,117 7-29-91 3C523.COM 12,238 7-29-91 EXOS.COM 20,194 11-08-91 LANSUP.COM 14,094 4-30-91 NE1000.COM 12,717 7-29-91 NE1500T.COM 21,840 10-11-91 NE2.COM 9,210 11-04-91 NE2-32.COM 12,737 7-29-91 NE2000.COM 13,018 6-03-91 NE2100.COM 21,836 10-11-91 NE3200.COM 19,242 9-03-91 PCN2L.COM 14,117 7-17-91 TOKEN.COM 15,663 6-14-91 TRXNET.COM 12,128 8-06-91 OSI LAN Drivers Driver File Size Date 3C503.LAN 12,370 7-26-91 3C505.LAN 21,798 8-20-91 3C527.LAN 15,355 7-17-91 NE1000.LAN 11,857 7-25-91 NE1500T.LAN 16,406 10-09-91 NE2.LAN 15,548 11-11-91 NE2-32.LAN 12,185 7-25-91 NE2000.LAN 12,389 7-26-91 NE2100.LAN 16,405 10-09-91 NE3200.LAN 19,198 1-15-92 PCN2L.LAN 10,434 7-24-91 TOKEN.LAN 10,324 9-09-91 TOKENDMA.LAN 9,177 10-25-91 TRXNET.LAN 11,691 8-19-91 OS/2 ODI Drivers Driver File Size Date 3C501.SYS 18,320 6-24-91 3C503.SYS 26,528 6-24-91 3C505.SYS 18,736 8-15-91 3C523.SYS 18,592 7-09-91 CMGRLAN.SYS 42,976 3-26-91 EXOS205.SYS 22,480 11-27-91 EXOS215.SYS 22,992 11-27-91 NE1000.SYS 19,424 6-24-91 NE1500T.SYS 21,008 12-13-91 NE2.SYS 20,448 6-24-91 NE2-32.SYS 19,568 6-24-91 NE2000.SYS 21,152 11-27-91 NE2100.SYS 20,992 12-13-91 PCN2L.SYS 13,632 10-11-91 TOKEN.SYS 25,392 12-13-91 TRXNET.SYS 21,824 12-17-91 TRXNET2.SYS 21,824 12-17-91